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Introduction 


The computational steps traditionally taken for most engineering analysis (CFD, structural 
analysis, and etc.) are: 

• Surface Generation - usually by employing a CAD system 

• Grid Generation — preparing the volume for the simulation 

• Flow Solver - producing the results at the specified operational point 

• Post-processing Visualization - interactively attempting to understand the results 

For structural analysis, integrated systems can be obtained from a number of commercial vendors. 
These vendors couple directly to a number of CAD systems and are executed from within the 
CAD GUI. It should be noted that the structures problem is more tractable than CFD; there are 
fewer mesh topologies used and the grids are not as fine (this problem space does not have the 
length scaling issues of fluids). 

For CFD, these steps have worked well in the past for simple steady-state simulations at the 
expense of much user interaction. The data was transmitted between phases via files. In most 
cases, the output from a CAD system could go IGES files. The output from Grid Generators and 
Solvers do not really have standards though there are a couple of file formats that can be used for a 
subset of the gridding (i.e. PLOT3D data formats). The user would have to patch up the data or 
translate from one format to another to move to the next step. Sometimes this could take days. 
Specifically the problems with this procedure are: 

• File based. Information flows from one step to the next via data files with formats specified for 
that procedure. File standards, when they exist, are wholly inadequate. For example, geometry 
from CAD systems (transmitted via IGES files) is defined as disjoint surfaces and curves (as 
well as masses of other information of no interest for the Grid Generator). This is particularly 
onerous for modem CAD systems based on solid modeling. The part was a proper solid and 
in the translation to IGES has lost this important characteristic. STEP is another standard for 
CAD data that exists and supports the concept of a solid. The problem with STEP is that a 
solid modeling geometry kernel is required to do anything with this type of file. 

• ‘Good’ Geometry. A bottleneck in getting results from a solver is the construction of proper 
geometry to be fed to the grid generator. With 'good geometry a grid can be constructed in 
tens of minutes (even with a complex configuration) using unstructured techniques. Adroit 
multi-block methods are not far behind. This means that a million node steady-state solution 
can be computed on the order of hours (using current high performance computers) starting 
from this ‘good’ geometry. Unfortunately, the geometry usually transmitted from the CAD 



system is not ‘good’ in the grid generator sense. The grid generator needs smooth closed solid 
geometry. It can take a week (or more) of interaction with the CAD output (sometimes by 
hand) before the process can begin. 

• One-Way Comminucation. All information travels on from one phase to the next. This makes 
procedures like node adaptation difficult w'hen attempting to add or move nodes that sit on 
bounding surfaces (when the actual surface data has been lost after the grid generation phase). 

Until this process can be automated, more complex problems such as multi-disciplinary' analysis 
or using the above procedure for design becomes prohibitive. There is also no way to easily deal 
with this system in a modular manner. One can only replace the grid generator, for example, if the 
software reads and writes the same files. 

Instead of the serial approach to analysis as described above, CAPRI takes a geometry centric 
approach. This makes the actual geometry (not a discretized version) accessible to all phases of the 
analysis. The connection to the geometry is made through an Application Programming Interface 
(API) and NOT a file system. This API isolates the top level applications (grid generators, solvers 
and visualization components) from the geometry engine. Also this allows the replacement of one 
geometry kernel with another, without effecting the top level applications. For example, if 
UniGraphics is used as the CAD package then Parasolid (UG’s own geometry engine) can be 
used for all geometric queries so that no solid geometry information is lost in a translation. This is 
much better than STEP because when the data is queried, the same software is executed as used in 
the CAD system. Therefore, one analyzes the exact part that is in the CAD system. 

CAPRI uses the same idea as the commercial structural analysis codes but does not specify 
control. Software components of the CAD system are used, but the control of the software session 
is specified by the analysis suite, not the CAD operator. This also means that the license issues 
(may be) minimized and individuals need not have to know how to operate a CAD system in 
order to run the suite. 



The CAPRI API 


CAPRI is a software building tool-kit that refers to two ideas; (1) A simplified hierarchical view 
of a solid part integrating both geometry and topology definitions, and (2) Programming access to 
this part and any attached data. 

A complete definition of the geometry and application programming interface can be found in the 
attached document “CAPRI: Computational Analysis PRogramming Interface”. In summary the 
interface is sub-divided into the following functional components: 

1 . Utility routines — These routines include the initialization of CAPRI, loading CAD parts and 
querying the operational status as well as closing the system down. 

2. Geometry data-base queries — This group of functions allow all top level applications to figure 
out and get detailed information on any geometric component in the Volume definition. 

3. Point queries -- These calls allow grid generators, or solvers doing node adaptation, to snap 
points directly onto geometric entities. 

4. Calculated or geometrically derived queries — These calls calculate data from the geometry to 
aid in grid generation. 

5. Boundary data routines — This part of CAPRI allows general data to be attached to Boundaries 
so that the boundary conditions can be specified and stored within CAPRI’s data-base. 

6. Tag based routines - This part of the API allows the specification of properties associated with 
either the Volume (material properties) or Boundary (surface properties) entities. 

7. Geometry based interpolation routines - This part of the API facilitates Multi-disciplinary 
coupling and allows zooming through Boundary Attachments. 

8. Geometric modification - This will be used for an automated design system where the goal of 
the application is to change the geometry. Routines that allow this have the advantage that if the 
data is kept consistent with the CAD package, then the design can be incorporated directly and 
therefore is manufacturable. 



Status of This Years Work 


1 . The white paper was written which describes the details of this new system. This has become 
the beginning of the documentation for CAPRI and is attached to the proposal as mentioned 
above. It includes the description of all but the last group of functions. 

2. A first cut of the API was written using Parasolid as the geometry engine. This choice is made 
because both GE and Pratt & Whitney use UniGraphics as their CAD software. ICAD also 
uses Parasolid as it’s low level solid modeller, therefore this geometry system is also 
supported. 

Though this was not specified in the proposal, a CAPRI port to Parametric Technology s 
Pro/ENGINEER was also performed. This gave some reassurance that CAPRI’s topology 
and geometry definitions were broad enough to support other solids-based CAD systems. 

Functional components 1-6 (listed above) have been written and tested using both Parasolid 
and Pro/TOOLKIT (the API into Pro/ENGINEER). The C and C++ interfaces are complete. 
The FORTRAN interface will be completed by the end of the current contract. 


3. Component 7, zooming and multi-disciplinary coupling, will be written and tested before this 
contract expires. Though simple in concept (mapping data to and extracting interpolated data 
from the actual geometry), the generalization is complex. To properly support turbomachinery 
applications it was necessary to include the idea of “replication” and movement of Volumes. 
This allows matching of the stator and rotor passages when the entire wheel is not simulated. 
Common visualization techniques like “mirroring” become a simple form of replication. 

4. On November 18, the first beta version of CAPRI will be delivered to Michael Aftosmis at 
NASA Ames Research Center. He is the author of a Cartesian mesh/solver external 
aerodynamics CFD system. This system requires the tessellation of surfaces, one of the data 
entities associated with the Face entity definition. It should be a simple port. Once complete, 
the point-query components can be used to snap surface grid nodes on the actual geometry (not 
the triangles of the tessellation). Aftosmis will use both the Parasolid version (he gets parts 
from McDonnell-Douglas - they also use UniGraphics) and he has access to a 
Pro/ENGINEER license. 



Statement of Work 


1. CAPRI and industry 

Clearly for this work to be successful, it must be used. The easiest way to convince industry of 
its value is to work on a topical problem of interest that current methods do not provide timely 
results. The following will be attempted in conjunction with Frank Sagendorph (Manager - 
Product Definition & Analysis Methodologies at GE Aircraft Engines): 

GE Aircraft Engines has a well established “Master Model” strategy in which UG part 
files and assemblies define a common geometry that is shared with discipline specific 
engineering and manufacturing applications. On the engineering side, these applications 
typically have to prepare the geometry for meshing, build the mesh, apply boundary 
conditions, solve the appropriate physics problem, display the results for interpretation and, 
if necessary, initiate another design iteration by changing the geometry. 

Although UG is GE’s core geometry modeler, frequently GE needs to operate on the 
geometry in a consistent fashion outside of the UG system. GE has developed pieces ot 
such a system, but there is room for improvement in both the fidelity of the geometric 
operations as well as the functionality for mesh creation and boundary condition 
application. A current port of the CAPRI system is based on a Parasolid geometry kernel, 
as is UG. Therefore GE’s interest is to evaluate CAPRI on a problem of considerable 
interest to Aircraft Engines to see if can fill in some of their missing capabilities. 

Specifically, we will use a high pressure turbine blade as the geometry for the evaluation. 
These blades have internal serpentine cooling passages which produce an extremely 
complex geometric definition. We have constructed UG models of these blades and these 
models would form the basis for our evaluation. The analysis models would address CFD, 
Heat Transfer and Mechanical Design needs. The evaluation will focus initially on these 
areas: 

A. Assessment of the overall accuracy of the geometry import from and export to 
UG. 

B. Ability to define and execute simple geometric operations inside CAPRI to prepare 
the geometry for meshing. For example, we might like to import the entire geometry and 
then de-construct it to isolate the airfoil, the platform, and the shank regions. 

C. Productivity gains which would could be attributed to the integrated graphics 
displays of CAPRI (the Geometry Viewer). 

E. Ease of integration with our existing in-house codes which generate meshes and 
apply boundary conditions for structural and CFD analysis models. 

F. Ease of integration with commercial packages such as ICEM-CFD and ANSYS. 

This evaluation will be conducted on HP workstations since they comprise the bulk of GE 
AE’s technical desktop computing resources. 

Future areas of interest would include the effective use of UG parametric models with 
CAPRI for more rapid design iterations. 



The CAD package CATIA will be the next to be integrated into the CAPRI framework. The 
proper licenses will be obtained to allow access to CATIA parts and the geometry kernel. 
CATIA is the only other major CAD vendor used by the aerospace industry currently not 
covered. This will allow Boeing access to CAPRI and therefore use and contribute to this 
work. 


3. Geometry Creation and Modification 

Once CATIA has been ported, the entire issue of modification and creation of solid-based 
geometry can be addressed. At a minimum, functions like scribing and splitting existing 
surface are required for grid generation of structured blocks as well as being able to bound and 
invert existing solids to create the fluid volume. 

With the knowledge of the internals of three major CAD systems, a group of functions can be 
specified so that these operations are feasable across these CAD packages. The goal is to 
produce an API that is both conceptually simple and very powerful. Boolean operations on 
solids may be the foundation for this part of CAPRI. 


4. Commercial Grid Generators 

The turbomachinery industry is beginning to use commercial grid generators. This causes a 
problem for CAPRI specifically and automated analysis and design systems in general. The 
work here requires that the grid generator use the solid model during the meshing and update 
the information in CAPRI with the surface discretization when complete. Wrappers can be 
written to merge the operations but a more complete integration is desirable. Attempts will be 
made to convince the vendors of these CFD grid generators to hook up to CAPRI (the 
packages include ICEM-Hexa, ICEM-Tetra, GridGen and GridPro). 


5. Assistance with Object Oriented DataBase coupling 

NASA Lewis Research Center personnel are now looking into the use of Object Orientated 
DataBases with and within analysis suites. CAPRI provides a natural test-bed for this work. 
Assistance will be rendered in using this framework. Parasolid will the first CAD kernel used 
in that it is easy to intercept the CAD part definition and change how and where it is read and 
written. 
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Abstract 

CAPRI is a CAD-vendor neutral application programming interface designed for the con- 
struction of analysis suites and design systems. By allowing access to the geometry from 
within all modules (grid generators, solvers and post-processors) such tasks as meshing on 
the actual surfaces, node enrichment by solvers and defining which mesh faces are bound- 
aries (for the solver and visualization system) become simpler. The overall reliance on file 
‘standards’ is minimized. 

This ‘Geometry Centric’ approach makes multi-physics (multi-disciplinary) analysis 
codes much easier to build. By using the shared (coupled) surface as the foundation, CAPRI 
provides a single call to interpolate grid-node based data from the surface discretization in 
one volume to another. Finally, design systems are possible where the results can be brought 
back into the CAD system (and therefore manufactured) because all geometry construction 
and modification are performed using the CAD system’s geometry kernel. 
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License 


This software is being provided to you, the LICENSEE, by the Massachusetts Institute of 
Technology (M.I.T.) under the following license. By obtaining, using and/or copying this 
software, you agree that you have read, understood, and will comply with these terms and 
conditions: 

Permission to use, copy, modify and distribute, this software and its documentation for 
any purpose and without fee or royalty is hereby granted, provided that you agree to compl) 
with the following copyright notice and statements, including the disclaimer, and that the 
same appear on ALL copies of the software and documentation: 

Copyright 1997 by the Massachusetts Institute of Technology. All rights reserved. 

THIS SOFTWARE IS PROVIDED “AS IS : ‘, AND M.I.T. MAKES NO REPRESEN- 
TATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT 
NOT LIMITATION, M.I.T. MAKES NO REPRESENTATIONS OR WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT 
THE USE OF THE LICENSED SOFTWARE OR DOCUMENTATION WILL NOT IN- 
FRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER 
RIGHTS. 

The name of the Massachusetts Institute of Technology or M.I.T. may NOT be used 
in advertising or publicity pertaining to distribution of the software. Title to copyright in 
this software and any associated documentation shall at all times remain with M.I.T., and 
USER agrees to preserve same. 
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1 Introduction 


The computational steps traditionally taken for Computational Fluid Dynamics (CFD), 
Structural Analysis, and other simulation disciplines (or when these are used in design) are: 

• Surface Generation 

The surfaces of the object (s) are generated usually from a CAD system. This creates 
the starting point for the analysis and is what is used for manufacturing. 

• Grid Generation 

These surfaces are used (with possibly a bounded outer domain) to create the vol- 
ume of interest. Usually for the analysis of external aerodynamics, the aircraft is 
surrounded by a domain that extends many body lengths away from the surfaces. 
This enclosed volume is then discretized (subdivided) in one of many different ways. 
Unstructured meshes are built by having the subdivisions usually comprised of tetra- 
hedral elements. Another technique breaks up the domain into sub-domains that 
are hexahedral. These sub-domains are further divided in a regular manner so that 
individual cells in the block can be indexed via an integer triad. 

• Flow Solver or Simulation 

The solver takes as input the grid generated by the second step (and information about 
how to apply conditions at the bounds of the domain). Because of the different styles 
of gridding, the solver is usually written with ability to use only one of the volume 
discretization methods. In fact there are no standard file types, so most solvers are 
written in close cooperation with the grid generator. For fluids, the solver usually 
simulates either the Euler or Navier-Stokes equations in an iterative manner, storing 
the results either at the nodes in the mesh or in the element centers. The output of 
the solver is a file that contains the solution. 

• Post-processing Visualization 

After the solution procedure has successfully completed, the output from the grid 
generator and the simulation are displayed and examined in a graphical manner by 
the fourth step in this process. Usually a workstation with a 3D graphics adapter is 
used to quickly render the output from data extraction techniques. The tools (such as 
iso-surfacing, geometric cuts and streamlines) allow the examination of the volumetric 
data produced by the solver. Even for steady-state solutions, much time is usually 
required to scan, poke and probe the data in order to understand the physics in the 
flow field. 

These steps have worked well in the past for simple steady-state simulations at the 
expense of much user interaction. The data was transmitted between phases via files (the 
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Figure 1: The Traditional Computational Analysis Suite 


arrows in Figure 1). In most cases, the output from a CAD system could go to IGES files. 
The output from Grid Generators and solvers do not really have standards though there are 
a couple of file formats that can be used for a subset of the problem space (i.e. PLOT3D 
data formats for CFD). The user would have to patch up the data or translate from one 
format to another to move to the next step. Sometimes this could take days. Specifically, 
the problems with this procedure are: 

• File based 

Information flows from one step to the next via data files with formats specified for 
that procedure. Historically, this allows individuals or groups to work in isolation on 
the construction of one of these components; unfortunately the user (or team) suffers 
greatly because of the lack of integration. In many cases the files that get used do not 
contain all the information required to couple all components so that the user can be 
removed from the mechanics of running the suite. 

• : Good' Geometry 

A bottleneck in getting results from a solver is the construction of proper geometry 
to be fed to the grid generator. With ‘good’ geometry a grid can be constructed in 
tens of minutes (even with a complex configuration) using unstructured techniques. 
Adroit multi-block methods are not far behind. This means that a million node 
CFD steady-state solution can be computed on the order of hours (using current high 
performance computers) starting from this ‘good' geometry. Unfortunately, geometry 
from CAD systems (especially when transmitted via IGES files) is not ‘good' in the 
grid generator sense. The data is usually defined as disjoint and unconnected surfaces 
and curves (as well as masses of other information of no interest for the mesh). The 
grid generator needs smooth closed solid geometrj'. It can take a week (or more) of 
interaction with the CAD output (sometimes by hand) before the process can begin. 
This is particularly onerous if the CAD system is based on solid modeling. The 
part was a proper solid with topology and in the translation to IGES has lost these 
important characteristics. 

• One-Way Communication 

All information travels on from one phase to the next. This makes procedures like 
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node adaptation difficult when attempting to add or move nodes that sit on bounding 
surfaces (when the actual surface data has been lost after the grid generation phase). 
In fact, the information passed from phase to phase is not enriched but is filtered. 

Until this process can be automated, more complex problems such as Multi-disciplinary 
analysis or using the above procedure for design becomes prohibitive. There is also no 
way to easily deal with this system in a modular manner. One can only replace the grid 
generator, for example, if the software reads and writes the same files. 

Procedures like zooming, defined within the Numerical Propulsion System Simulation 
(NPSS), are difficult to acheive when the surface definition for the coupling between the 
simulations is lost. 
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2 CAPRI 


Instead of the serial approach to analysis as described above, CAPRI uses a geometry 
centric approach. This makes the actual geometry (not a discretized version) accessible to 
all phases of the analysis. The connection to the geometry is made through an Application 
Programming Interface (API) and NOT a file system. This API isolates the top level 
applications (grid generators, solvers and visualization components) from the geometry 
engine. Also this allows the replacement of one geometry kernel with another, without 
effecting the top level applications. For example, if UniGraphics is used as the CAD package 
then Parasolid (UG's geometry engine) can be used for all geometric queries so that no solid 
geometry information is lost in a translation. If Pro/E is used then Pro/Toolkit is accessed 
when geometric information is required. See Figure 2. 



Figure 2: The CAPRI based Computational Analysis Suite 


It is verv important to consider the design goals when building a new software architec- 
ture. Without properly setting a broad foundation, the system may not be able to function 
as desired. The goals for CAPRI are: 

• Modular 

The system must support a modular or building-block method for construction. This 
facilitates a plug and play approach at the top level as well as the underlying geometry 
kernel. 

• Multiple languages 

It is important to support FORTRAN, C and C++. Many CFD codes are currently 
written in FORTRAN. On many machines, the FORTRAN compiler produces more 
highly optimized code, giving much better performance. Forcing the core of these 
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algorithms to another language, just because the rest of the system is in that language, 
is not be part of the philosophy found in CAPRI. 

• Transient solutions 

This system must support unsteady simulations as well as steady-state, which include 
the underlying geometry changing with time. 

• Allow Multi-discipline coupling and zooming 

This system must be general enough to allow coupling from codes of other disciplines 
(including but not limited to - structural analysis, heat transfer, acoustic codes). In 
fact the coupling could be close, in that the analysis code could be made a part of the 
overall design system. 

2.1 Geometry and Topology 

To insure that, the design goals can be met and the resulting interface is not overly complex, 
it is crucial that the geometry description be uncomplicated (but not too simple as to 
impair functionality). Most systems that deal with CAD data make the distinction between 
geometry (points, curves and surfaces) and topology (the hierarchical connections between 
geometric entities). CAPRI mixes these in a simple geometry data definition. 

The geometry and topology are defined in CAPRI in the following mannei. 


• Nodes 

These are the simplest entities and are just points in 3 space. 

• Edges 

Edges arc curves. Each Edge is bounded by tw'o unique Nodes. The Edge is param- 
eterized with £, w'here the first Node has a value at t m i n and the second bounding 
Node has a value of £ mGX - The value of t m j n is ahvays less than t max , 

To aid in plotting, there is an attached discretization of the curve. This is defined as 
a poly-line with a specified length. The line is defined starting at the first Node and 
terminates with the second. 

Note: Circles, ellipses and other closed loops found in the original CAD definition are 
broken up by CAPRI so that there is no parameterization that is periodic. Any closed 
loop will be broken in two and therefore may have two Nodes added so that the Edge 
can be properly bounded. 

• Faces 

Faces are parameterized (u, u) surfaces. The parameter range for u is u mzn to u maz 
and v ranges from v min to v max . but the relationship between (u, v) and the bounding 
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Edges is not as simple as the Edge-Node definitions. This is because Faces may be 
bounded by more than 4 Edges. In fact, a Face can be a very complex surface where 
the ranges of the parameterization are only limits and should not be used throughout 
its entirety (i.e. there may be a hole or the result of some trimming). 

The bounds of the Face are defined by closed set(s) of Edges. There may be one or 
more of these loops for each Face. Stored with each defining Edge is an orientation so 
that it is known whether to look at the Edge as specified or in the opposite sense. The 
loop is an ordered suite that defines the orientation of the Face. The outer loop(s), 
specify the boundary of the surface, and traverse the Face in a right-handed manner 
- defining the outward pointing normal (out of the volume). Any holes are specified 
by a left-handed traversal of Edges. See Figure 3. 



Node 


Figure 3: A simple Volume with a cylinder cutout - Edges marked for front Face 


Each Edge can be found bounding two Faces, one in the forward and one in the 
opposite sense. 

Again, to aid in plotting and to have a complete representation of this (possibly 
complex) Face, there is an attached discretization. This is defined as suite of disjoint 
triangles of a specified length. Each triangle is right-handed with the normal pointing 
out of the volume. 

Note: Cylinders, and other periodic surfaces found in the original CAD definition 
are broken up by CAPRI so that the parameterization is not periodic. Any periodic 
surface will be broken in two and therefore may have two Edges added so that the 
Face’s parameter space is simple. 

• Boundaries 

Boundaries are simply collect ions of one or more Faces. These entities are the connec- 
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tion between the geometry and the rest of the analysis suite, as described above. The 
Faces need not couple together (i.e. , a periodic boundary upstream and downstream 
from a turbine or compressor blade) but are used to insure that the grid generation 
knows that these surfaces could be treated in special ways. And, the solver knows 
which boundary condition to apply to what section of the resultant mesh. 

Boundaries have an associated name (i.e., far-field, body, wing and etc). 

• Volumes 

Volumes are completely closed regions of 3 space. Volumes are bounded by the sum of 
all of the Faces found in the Boundaries. These Faces match up at the shared Edges, 
that terminate at the Nodes. CAPRI can handle one or more Volumes at a time. 

Each Volume can be named with strings like; ’Fluids passage’, 'Blade', and etc. 

Volumes may have a number of associated Tags to indicate global conditions for the 
discipline. Each Tag has an assigned value string. For example; the Volume 'Fluids 
passage’ may have the Tags ‘gamma’ (with the value string of T.4’) and ‘smoothing’ 
(with the associated string ‘0.2 0.02'). 

The geometric entities described above are handled within CAPRI with integer handles 
or indices. Each Volume is assigned a handle when loaded. All entities contained within 
that volume (Nodes, Edges, Faces and Boundaries) are given indices ranging from 1 to the 
total number of entities in that class. Therefore, it usually requires 2 handles to describe 
an entity, the volume and the entity indices. 

There is a special Boundary index (zero) which refers to all currently unassigned Faces. 
When a Volume (or number of Volumes) is first read from the CAD system, this Boundary 
is fully populated with all Faces. As Faces become assigned, they are pulled from this 
Boundary and put in the appropriate place. 

2.2 Boundaries 

Boundaries are the pivotal data objects used within CAPRI. Boundaries are the entities 
that the grid generators should build the exposed parts of the mesh about. Different solver 
functions (boundary conditions) are then applied across these facets of the volume. When 
Multi-disciplinary analysis are run, boundaries are where these different physical models 
share information to drive the coupled solution. 

The data that comes from CAD systems does not always provide a proper separation 
of surfaces (Edges, as specified above) that coincide with what is required by the analysis 
suite. This is for two reasons; (1) the CAD operator, by the order of construction, may 
produce artifacts (such as sliver surfaces) or detail at a level more complex than the analysis 
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suite requires. (2) Curved surfaces such as fillets have breaks, on where these surfaces mate 
with other surfaces, usually not at the center of curvature where the analysis suite would 
require the edge of the boundary. 

The first of these problems is resolved in CAPRI by allowing the collection of CAD 
surfaces. The analysis suite can query this collection and get to the detailed CAD surfaces 
if required. This has the advantage over what is done in automated techniques used for 
grid generation in that the CAD artifacts can be meshed through as opposed to becoming 
features in the grid. For example, a sliver surface would end up completeh resohed, in an 
automated surface gridding procedure, requiring potentially large numbers of small cells in 
those regions. 

Scribing and splitting CAD surfaces so that the analysis boundaries can be defined is 
a function of CAPRI. Initially this is done interactively or through program control (if the 
analysis suite can determine where to break the surfaces). In the future, work will be done 
to attempt to automate this procedure. 

Interactive functions are also provided within the CAPRI framework to collect these 
CAD surfaces and produce the boundaries as well as setting up the information to run the 
entire suite. 

2.2.1 Boundary Discretization 

Each Boundary can have an attached discretization. This discretization can be from dif- 
ferent mesh topologies that touch the Boundary. There are 3 types of cell faces that build 
this structure: 

• Disjoint Triangles - 3 bnodes per entity 

• Disjoint Quadrangles - 4 bnodes per entity 

• Quad-Meshes - these are produced from grid ‘planes’ of structured blocks 

These entities are supported via Boundary nodes (bnodes). The bnode numbering used 
is local within the Boundary. The node numbering used differentiates between the nodes 
in the non-block regions (formed by the disjoint faces) and the structured blocks. Figure 4 
shows a schematic of the bnode space, ndnode is the number of nodes for the non-block 
(disjoint primitive) grid. Each Quad-AIesh (m) adds A I m * A Jm * A A m nodes to the node 
space (where AT, NJ and ATv are the number of nodes in each direction). The node 
numbering within the block follows the memory storage, that is, (i,j,k) in FORTRAN and 
[k] Li] [i] in C. The bnode number = base + i + ( j — 1) * AT m + (k — 1) * A 7 m * A J m . 
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Notes: 

1) All indices start at 1. 

2) Either _YJ, XJ or XK must be 1 for each Quad-Mesh. 

3) Disjoint Tri and Quad definitions may contain nodes defined within the Quad-Meshes. 

Quad-Meshes 


l 


1 ndnode nbnode 


Figure 4: Boundary Node Space 


2.2.2 Special Groupings 

Special groupings are simply lists of bnodes that may be required by the solver s boundary 
condition routines. This is to flag “special” nodes. For example, if IBlanking is used, 
there could be a list that contains the IBlanked nodes. If nodes along the Edges between 
Boundaries need to be treated differently from those interior nodes, then these edge nodes 
can be placed in a Special group. 

2.2.3 Boundary Attachments 

Boundary attachments are collections of data that are associated with the bnodes of the 
Boundary discretization. The attachments are identified by a name and can have an addi- 
tional string that can indicate information on how and/or when the attachment was created. 
These attachments can be used to communicate boundary level data between modules (i.e., 
heat transfer to the visualization module), perform Zooming or otherwise couple like simu- 
lations at boundaries and perform multi-disciplinary coupling between Volumes. 

2.2.4 Boundary Tags 

Tags are character strings associated with the Boundary. Each string has an attached value 
string. These Tag entities are useful for specifying conditions or material information for 
the application of boundary conditions by the solver. For example; the Boundary named 
‘Walk may have a Tag ‘temperature' with the associated value ‘300K’. 
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2.3 The CAPRI API 


The CAPRI API is sub-divided into the following components: 

1. Utility routines 

These routines include initialization of CAPRI, loading CAD parts and querying sta- 
tus as well as closing the system down: 

• gLuStart - Initialize CAPRI 

• gLuLoadPart - Loads a Volume or number of Volumes from a CAD part 

• gLuSavePart. - Save away the CAD part 

• gLuNum Volumes Returns the number of active Volumes 

• gLuStop - Terminates CAPRI 

2. Geometry data-base queries 

This allows all top level applications to figure out and get detailed information on any 
geometric component in the Volume definition: 

• gLdGetNode - Returns the data for a Node 

• gi.dGetEdge - Returns the data for an Edge 

• gLdGetFace - Returns the data for a Face 

• gLdGetBoundary - Returns the data for a Boundary 

• gLdNewBoundary - Creates a new Boundary for the Volume 

• gLdMoveFace - Moves a Face from one Boundary to another 

• gLdXameVolume - Assigns a string to a Volume 

• gLdGetVolume - Returns the name of the Volume and the number of Nodes, 
Edges, Faces and Boundaries attached 

• gi.dBox - Returns the min and max coordinates for the Volume 

3. Point queries 

These calls allow grid generators, or solvers doing node adaptation, to snap points 
directly on geometric entities: 

• gi.qPoint O nEdge - Returns the point at the t parameter and optionally derivi- 
tives 

• gi .qNeares t O nEdge - Returns the t parameter given a point 

• gi.qPoint OnFace - Returns the point at the (u,v) parameters and optionally 
derivitives 
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• gLqXearestOnFace - Returns the (u, i?) parameters given a point 

• gLqXormalToFace - Returns the normal to the given (it,v) parameters 

• gi.qlnEdge - Returns whether the given point is on the Edge. 

• gLqlnFace - Returns whether the given point is in the Face or not (in some hole 
or trimmed-off region) 

• gLdlnBoundary - Returns whether the given point is in the Boundary and asso- 
ciated Face index if it is. 

• gLqlnVolume - Returns whether the given point is contained within the specified 
Volume 

4. Calculated or geometrically derived queries 

These calls calculate data from the geometry to aid in grid generation: 

• gi_cLengthOfEdge - Returns the arc-length of the Edge 

• gi_cCurvOfEdge - Returns the curvature at a point on the Edge 

• gLcMaxCurvOfEdge - Returns the maximum Face curvature of a point on the 
Edge 

• gi.cCurvOfFace - Returns the curvatures and principal directions at a point on 
the Face 

• gLcMaxCurvOfFace - Returns the maximum curature of a point on the Face 

5. Boundary data routines 

This part of CAPRI allows general data to be attached to Boundaries so that the 
boundary conditions can be specified and stored within CAPRIs data-base: 

• gLbSetDiscret - Sets the discretization for the Boundary 

• gLbGetDiscret - Returns the discretization for the Boundary 

• gi.bGet Coord - Returns the discretization coordinates 

• gLbGetTris - Returns the disjoint triangle discretization 

• gi.bGetQuads - Returns the disjoint quad discretization 

• gi.bGetQMesh - Returns the quad-mesh discretization 

• gi_bGet3DNode - Translate boundary node index to 3D mesh node 

• gi.bSetSpecial - Set/Update a Special grouping 

• gLbGetSpecial - Return data about a Special grouping 

• gLbGetlSpecial - Return data about a Special grouping (by index) 

• gLbDelSpecial - Removes a Special grouping 
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6. Geometry based interpolation routines 

This part of the API facilitates Multi-disciplinary coupling and allows zooming through 
Boundary Attachments: 

• gi-iSet Attach - Set/Update a Boundary Attachment 

• giJGet Attach - Return data about a Boundary Attachment 

• gi_iGetIAttach - Return data about a Boundary Attachment (by index) 

• gi-iDelAttach - Removes a Boundary Attachment 

• gLiGet Displace - Returns Volume displacement matrix used for interpolation 

• giJSetDisplace - Specifies Volume displacement matrix 

• gUGetReplicate - Returns Volume replication used for interpolation 

• gLiSetReplicate - Specifies Volume replication for interpolation 

• gi.ilnterAttach - Interpolate to produce/update Boundary Attachment 

7. Tag based routines 

This part of the API allows the specification of properties associated with either the 
Volume or Boundarj- entities: 

• gLtGetXum Volume - Returns the number of Volume Tags 

• gLtGetVolume - Return associated string for the specified Tag 

• gLtGetIVolume - Return data for the specified Tag (by index) 

• gLtSetVolume - Set/Update a Tag 

• gLtGetXumBoundary - Returns the number of Boundary Tags 

• gLtGetBoundary - Return associated string for the specified Tag 

• gLtGetIBoundary - Return data for the specified Tag (by index) 

• gLtSetBoundary - Set/Update a Tag 

8. Geometric modification 

This will be used for an automated design system where the goal of the application 
is to change the geometry. Routines that allow this have the advantage that if the 
data is kept consistent with the CAD package, then the design can be incorporated 
directly and therefore is manufacturable. 

Not yet defined! 
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3 The Geometry Viewer 


The Geometry Viewer is not an integral part of the CAPRI API, but is a stand-alone tool- 
kit that augments CAPRI. It is designed to be able to become the visual interface to the 
entire analysis suite. 

The Geometry Viewer has been written to be modular and attachable to applications 
that that deal with point, line, surface and volume data. The Viewer has two execution 
modes; (1) normal, serial, execution where program control is passed to the graphics, the 
data is examined and then when the user is satisfied, execution resumes in the calling pro- 
gram. (2) Multi-threading where the data is shared between to executing threads (applica- 
tion and graphics) and both can be concurrently active allowing viewing as the application 
runs. This is particularly useful in the debugging of grid generators. 

The user interface is multi-windowed and has the same look and feel as \ isual3 appli- 
cations and the p\ 3 Server and \ iewer. Because the Geometry \ iewer was not designed as 
a scientific visualization system, there is only the ability to deal with grids and geometij. 
More effort has been put towards lighting models and the ability to light either faceted (nor- 
mals based on cell faces) as well as smoothly (normals based on nodes). The 2D window is 
only used for a planar cutting surface so that the interior of volumes may be examined. 

The Geometry Viewer has the following features: 

• OpenGL 

All 3D and 2D rendering is performed in OpenGL to achive high performance and 
good animation. 

• 3D Viewing 

Items may be rendered in a specified color or colored via scalars that are either defined 
at nodes or facets. The line and surface primitives may be either indexed (based on a 
list of points) or non-indexed. The following attributes may be interactively adjusted: 

- Points: Rendering on/off 

— Lines: Rendering on/transparent/off, Moved forward (not obscured by surfaces), 
Orientation (direction) on/off 

- Surfaces: Rendering on/transparent /off, Lighting faceted/smooth, Orientation 
(front vs. back) on/off, Mesh on/moved forward/off. 

• 2D Viewing 

The intersection of the plane and lines are plotted as points in the 2D window. Inter- 
sected surfaces are displayed as curves. Any 3D mesh that is cut is displayed as the 
intersected cell faces (lines) within the volume. 
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• Picking and Locating. Picking (pointing at and selecting objects) in the 3D window is 
supported. This is useful in CAPRI for specifying the Boundary entities interactively. 
Locating (3D pointing and retrieving 3 space coordinates) is useful for interactive 
modification of geometry. 

• Data-base A window is dedicated to the objects within the Geometry Viewer. This is 
were the interactive control of the plotting attributes is performed. 
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A Utility Calls 


A.l Start - Initialize CAPRI 

icode = gi_uStart() 

ICODE = IG_USTART() 

This must be the first call to CAPRI. It initializes the system. 

I: icode Return code 

A. 2 LoadPart - Load Volume(s) from CAD part file 

icode = gi_uLoadPart(char *name) 

ICODE = IG_ULOADPART(NAME) 

Before examining any CAD data a “solids’' part must be loaded. 

C: name Character string containing the file-name for the part 

I: icode Return code 

A. 3 SavePart - Save Volume(s) to CAD part file 

icode = gi_uSavePart(char *name) 

ICODE = IG-USAVEPART(NAME) 

This call allows the output of the part once data has been modified. 

C: name Character string containing the file-name for the part - 

should be a different name than used to read the part 

I: icode Return code 

A. 4 NumVolumes - Returns the Number of Active Volumes 

numVl — gi_uNumVolumes() 

NUMVL = IGJJNUM VOLUMES () 

Any negative return is the indication of an error. 

I: numVl Number of Yolumes/Return code 


20 



A. 5 Stop - Terminate CAPRI 


icode = gLuStop(exit) 

ICODE = IG-USTOP(exit) 

This must be the last call to CAPRI. It terminates the system and frees up all memory. 
CAPRI will need to be re-initialized before using any functions. 

I: exit 
I: icode 


0 - return; otherwise exit in the appropriate manner. 
Return code 
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B Geometry Data-Base Queries 

B.l GetNode - Returns the Data for a Node 


icode = gi_dGetNode(int vol, node, double *point) 
ICODE = IG_DGETNODE(VOL, NODE, POINT) 

Returns the 3D coordinates associated with the Node. 


I: vol 

Volume index 

I: node 

Node index 

D: point 

Point - length 3 (returned) 

I: icode 

Return code 

B.2 GetEdge - 

Returns the Data for an Edge 


icode = gi_dGetEdge(int vol, edge, double *trange, int *nodes, *npts, 

double **points) 

ICODE = IG_DGETEDGE(VOL, EDGE, TRANGE, NODES, NPTS, POINTS) 

Returns the data associated with the Edge. 


I: vol 

Volume index 

I: edge 

Edge index 

D: trange 

t min and t max - length 2 (returned) 

I: nodes 

Node endpoint indices - length 2 (returned) 

I: npts 

Number of points in discretization (returned) 

D: points 

pointer to polyline discretization (returned) 

I: icode 

Return code 


FORTRAN note: The pointer is not returned. NPTS must be set with the size of 
POINTS at the call. It is returned with the actual length. If POINTS is not declared large 
enough (by the calling routine) the return code CAPRI-OVERFLOW is set but all the data 
up to that length is correct. 
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B.3 GetFace - Returns the Data for a Face 


icode = gLdGetFace(int vol, face, double *urange, 

int *nloop, **loops, **edges, *npts, double **points) 
ICODE = IG_DGETFACE(VOL, FACE, URANGE, NLOOP, LOOPS, NPTS, 

POINTS) 

Returns the data that defines the Face. 


I: vol 
I: face 
D: urange 
I: nloop 
I: loops 
I: edges 


I: npts 

D: points 
I: icode 


Volume index 
Face index 

Wmm? ^ min ? ^ max snd r max — length 4 (returned) 

Number of Edge loops (returned) 
pointer to Edge loop lengths (returned) 

pointer to Edge data that make up all of the loops, each 
entry contains 2 integers, first the Edge index and second 
the sense (—1 or 1) - data length is the sum of all loop 
lengths (returned) 

Number of points in disjoint triangle descritization (re- 
turned) 

pointer to the disjoint triangle discretization (returned) 
Return code 


FORTRAN notes: Pointers are not returned — > 

1) NLOOP must be set with the length of LOOPS and LOOPS(l) must be set with the 
size of EDGES befoi'e the call is executed. LOOPS and EDGES are filled with the actual 
data and NLOOP is set with the number of loops for the Face. If either of the declared 
lengths are not long enough to store the data, then the return code CAPRLOYERFLOW 
is set. Information is filled up to that limit. 

2) NPTS must be set with the size of POINTS at the call. It is returned with the actual 
length. If POINTS is not declared large enough (by the calling routine) the return code 
CAPRLOYERFLOW is set but all the data up to that length is correct. 
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B.4 GetBoundary - Returns the Data for a Boundary 

icode = gi_dGetBoundary(int vol, bound, *nface, **faces, char **name) 
ICODE = IG-DGETBOUNDARY (VOL, BOUND, NFACE, FACES, NAME) 

Returns the data associated with the Boundary. 


I: vol 

Volume index 

I: bound 

Boundary index (0 - “Un Assigned ) 

I: nface 

Number of faces (returned) 

I: faces 

pointer to the faces (returned) 

C: name 

pointer to character string (returned) 

I: icode 

Return code 


FORTRAN note: The pointer is not returned. XFACES must be set with the size of 
FACES at the call. It is returned with the actual length. If FACES is not declared large 
enough (by the calling routine) the return code CAPRI.OYERFLOV is set but all the data 
up to that length is correct. 

B.5 NewBoundary - Creates a New Boundary for the Volume 

icode = gi_dNewBoundary(int vol, char *name) 

ICODE = IG_DNEWBOUNDARY (VOL, NAME) 

Creates the new Boundary for the volume with the given name. 

I: vol Volume index 

C: name character string for the name of the Boundary 

I: icode Created Boundary index/Return code 
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B.6 MoveFace - Assigns a Face to a Boundary 


icode = gi_dMoveFace(int vol, face, bound) 

ICODE = IG_DMOVEFACE(VOL, FACE, BOUND) 

Moves the Face from one Boundary to the assigned Boundary index. Note: All current 
discretizations, groupings and attachments are removed from both source and destination 


Boundaries. 


I: vol 

Volume index 

I: face 

Face index 

I: bound 

Boundary index - target 

I: icode 

Return code 

B.7 NameVolume 

- Assign a Title to a Volume 

icode = gi_dNameVolume(int vol, char *name) 
ICODE = IG_DNAMEVOLUME(VOL, NAME) 

Gives the Volume a name. 

I: vol 

Volume index 

C: name 

character string assigned to the volume 

I: icode 

Return code 

B.8 Get Volume - 

Returns the Data for a Volume 

icode = gi_dGetVolume(int vol, *nnode, *nedge, *nface, *nbound, 

char **name) 

ICODE = IGJDGET VOLUME (VOL, NNODE, NEDGE, NFACE, NBOUND, 

NAME) 

Returns the number of entities associated with the Volume index. 

I: vol 

Volume index 

I: nnode 

number of Nodes associated with the volume (returned) 

I: nedge 

number of Edges associated with the volume (returned) 

I: nface 

number of Faces associated with the volume (returned) 

I: nbound 

number of Boundaries found within the volume (returned) 

C: name 

pointer to the string for the Volume’s name (returned) 

I: icode 

Return code 
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B.9 Box - Return the Bounding Coordinates for the Volume 

icode = gi_dBox(int vol, double *box) 

ICODE = IG_DBOX(VOL, BOX) 

Returns the coordinate box that contains the \ olume. 


I: vol 

Volume index 

D: box 

^ min • Zt\ min ? ^ max an( ^ Z max ~ length 6 (re- 

turned) 

I: icode 

Return code 
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C Point Queries 

C.l PointOnEdge - Returns the Coordinates On the Edge 


icode = gi_qPointOnEdge(int vol, edge, double t, *point, int der, 

double *dl, *d2)) 

ICODE = IG_QPOINTONEDGE(VOL, EDGE, T, POINT, DER, Dl, D2) 

Returns the Point and derivitives (optionally) at the t parameter. 


I: vol 
I: edge 
D: t 

D: point 
I: der 


D: dl 
D: d2 
I: icode 


Volume index 
Edge index 
t parameter 

Point - length 3 (returned) 

Derivative Flag: 

0 - No derivatives (only return point) 

1 - Compute and return first derivative 

2 - Compute and return first and second derivatives 

First derivative - length 3 (returned, der > 0) 
Second derivative - length 3 (returned, der > 1) 
Return code 


C.2 NearestOnEdge - Finds the Nearest Position to the Edge 

icode = gi_qNearestOnEdge(int vol, edge, double *coor, *point, *t) 
ICODE = IG_QNEARESTONEDGE(VOL, EDGE, COOR, POINT, T) 

Returns the closest coordinates to the input point on the Edge and the t parameter. 


I: vol 

Volume index 

I: edge 

Edge index 

D: coor 

Input point - length 3 

D: point 

Point - length 3 (returned) 

D: t 

t parameter (returned) 

I: icode 

Return code 
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C.3 PointOnFace - Returns the Coordinates On the Specified Face 


icode = gi_qPointOnFace(int vol, face, double u, v, *point, int der, 

double *du, *dv, *duu, *duv, *dvv) 

ICODE = IG_QPOINTONFACE(VOL, FACE, U, V, POINT, DER, DU, DV, 

DUU, DUV, DVV) 

Returns the Point and derivitives (optionally) at the (u,v) parameters. 


I: vol 
I: face 
D: u 
D: v 
D: point 
I: der 


D: du 
D: dv 
D: duu 
D: duv 
D: dvv 
I: icode 


Volume index 
Face index 
u parameter 
v parameter 

Point - length 3 (returned) 

Derivative Flag: 

0 - Xo derivatives (only return point) 

1 - Compute and return first derivative 

2 - Compute and return first and second derivatives 

First derivative of u - length 3 (returned, der > 0) 
First derivative of v - length 3 (returned, der > 0) 
Second derivative of u - length 3 (returned, der > 1) 
Cross derivative - length 3 (returned, der > 1) 
Second derivative of v - length 3 (returned, der > 1) 
Return code 


C.4 NearestOnFace - Finds the Nearest Position to the Face 

icode = gi_qNearestOnFace(int vol, face, double *coor, *point, *u, *v) 
ICODE = IG_QNEARESTONFACE(VOL, FACE, COOR, POINT, U, V) 

Returns the closest coordinates to the input point on the Face and the (u, v) parameters. 


I: vol 

Volume index 

I: face 

Face index 

D: coor 

Input point - length 3 

D: point 

Point - length 3 (returned) 
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D: u 


u parameter (returned) 
v parameter (returned) 
Return code 


D: v 
I: icode 

C.5 NormalToFace - Finds the Normal at the Specified Parameters 

icode = gi_qNormalToFace(int vol, face, double u, v, *point, *norm) 
ICODE = IG_QNORMALTOFACE(VOL, FACE, U, V, POINT, NORM) 

Returns the normal to the Face at the (u, v) parameters. 


I: vol 

Volume index 

I: face 

Face index 

D: u 

u parameter 

D: v 

r parameter 

D: point 

Point - length 3 (returned) 

D: norm 

Normal - length 3 (returned) 

I: icode 

Return code 

C.6 InEdge 

- Is the Point Contained in the Edge 


icode = gi_qInEdge(int vol, edge, double *point) 
ICODE = IG_QINEDGE(VOL, EDGE, POINT) 

Returns a condition indicating whether the point is on the Edge. 


I: vol 

Volume index 

I: edge 

Edge index 

D: point 

Point - length 3 

I: icode 

Return code - CAPRI.OUTSIDE is returned when the 
point is not contained on the Edge 
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C.7 InFace - Is the Point Contained on the Face 


icode = gLqInFace(int vol, face, double *point) 
ICODE = IG_QINFACE(VOL, FACE, POINT) 

Returns a condition indicating whether the point is on the Face. 


I: vol 

Volume index 

I: face 

Face index 

D: point 

Point - length 3 

I: icode 

Return code - CAPRLOUTSIDE is returned when the 
point is not contained on the Face 


C.8 InBoundary — Is the Point Contained on the Boundary 


icode = gi_qInBoundary(int vol, bound, double *point, int *face) 
ICODE = IG-QINBOUND ARY (VOL, BOUND, POINT, FACE) 

Returns a condition indicating whether the point is on the Boundary. 


I: vol 

Volume index 

I: face 

Bound index 

D: point 

Point - length 3 

I: face 

Face index for Face containing the point (returned) 

I: icode 

Return code - CAPRLOUTSIDE is returned when 
point is not contained on the Boundary 


C.9 InVolume - Is the Point Contained within the Volume 

icode = gi_qInVolume(int vol, double *point) 

ICODE = IG_QINVOLUME(VOL, POINT) 

Returns a condition indicating whether the point is in the Volume. 

I: vol Volume index 

Point - length 3 

Return code - CAPRLOUTSIDE is returned when the 
point is not contained within the Volume 


D: point 
I: icode 



D Calculated or Geometrically Derived Queries 

D.l LengthOfEdge - Returns the arc-length of the Edge 

icode = gi_cLengthOfEdge(int vol, edge, double tl, t2, *len) 
ICODE = IG_CLENGTHOFEDGE(VOL, EDGE, Tl, T2, LEN) 

Returns the length along the Edge between the parameter range ti and £ 2 - 


I: vol 

Volume index 

I: edge 

Edge index 

D: tl 

t parameter for the start of the calculation 

D: t'2 

t parameter for the end of the calculation - t\ must be less 
than * 2 - 

D: len 

the resultant length (returned) 

I: icode 

Return code 

D.2 CurvOfEdge - 

Gets the tangent and curvature for an Edge point 


icode = gi_cCurvOfEdge(int vol, edge, double t, *tang, *curv) 
ICODE = IG_CCURVOFEDGE(VOL, EDGE, T, TANG, CURV) 

Returns the curvature and unit tangent found at t along the Edge. 


I: vol 

Volume index 

I: edge 

Edge index 

D: t 

t parameter along the Edge 

D: tang 

the unit tangent - length 3 (returned) 

D: curv 

the curvature (returned) 

I: icode 

Return code 
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D.3 MaxCurvOfEdge - Gets the maximum curvature for the attached 


Faces 


icode = gi_cMaxCurvOfEdge(int vol, edge, double t, *curv) 

ICODE = IG_CMAXCURVOFEDGE(VOL, EDGE, T, CURV) 

Returns the maximum curvature found at t along the Edge for the Faces that share the 

Edge. 


I: vol 

Volume index 

I: edge 

Edge index 

D: t 

t parameter along the Edge 

D: curv 

the maximum curvature (returned) 

I: icode 

Return code 

D.4 CurvOfFace 

- Gets the principal directions and curvature at a Face 

point 


icode = gi_cCurvOfFace(int vol, face, double u, v, *dirl, *curl, *dir2, *cur2) 
ICODE = IG_CCURVOFFACE(VOL, FACE, U, V, DIR1, CUR1, DIR2, CUR2) 

Returns the curvature and principle directions at (u, v) in the Face. 

I: vol 

Volume index 

I: face 

Face index 

D: u 

u parameter for the Face 

D: v 

v parameter for the Face 

D: dirl 

the first principal direction - length 3 (returned) 

D: curl 

the curvature for first principal direction (returned) 

D: dir2 

the second principal direction - length 3 (returned) 

D: cur2 

the curvature for second principal direction (returned) 

I: icode 

Return code 
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D.5 MaxCurvOfFace - Returns the maximum curvature of a Face point 


icode = gLcMaxCurvOfFace(int vol, face, double u, v, *curv) 
ICODE = IG_CMAXCURVOFFACE(VOL, FACE, U, V, CURV) 

Returns the maximum curvature found at (u, v) in the Face. 


I: vol 

Volume index 

I: face 

Face index 

D: u 

u parameter for the Face 

D: v 

v parameter for the Face 

D: curv 

the maximum curvature (returned) 

I: icode 

Return code 
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E Boundary data routines 

E.l SetDiscret - Declares the Discretization for the Boundary 


icode = gi_bSetDiscret(int vol, bound, ndnode, ntris, nquads, nqmeshs, 

flag, *nbnode) 

ICODE = IG_BSETDISCRET(VOL, BOUND, NDNODE, NTRIS, NQUADS, 

NQMESHS, FLAG, NBNODE) 

This routine sets the grid discretization for the Boundary. This may be comprised of a 
homogenous or heterogenous collection of disjoint triangles, disjoint quadrangles and quad- 
meshes. This call implicitly defines a boundary node (bnode) numbering, where NDNODE 
is the number of nodes associated with the disjoint primitives, the rest of the bnodes are 
defined from the quad-meshes (attached to structured blocks). This routine will cause the 
execution of as many as 5 supplied routines, based on the arguments. These call-backs 
define the collection of data for the bnodes, triangles, quadrangles, quad-meshes and node 
coordinates. 


I: vol 
I: bound 
I: ndnode 
I: ntris 
I: nquads 
I: nqmeshs 
I: flag 


I: nbnode 
I: icode 


Volume index 
Boundar}' index 

Number of nodes associtated with the disjoint primitives 
Number of disjoint triangles assigned to the Boundary 
Number of disjoint quadrangles assigned to the Boundary 
Number of quad- meshes (from structured blocks) 

Update flag (if the Discretization changes): 

0 - Remove all Attachments and Special groupings 

1 - Remove all Special groupings, interpolate to new 

bnodes for Attachments 

Total number of bnodes for the Boundary (returned) 
Return code 


NOTE: If ntris, nquads and nqmeshs are all zero, then the descritization is removed. 
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gibFillCoord(int vol, bound, nbnode, double *xyz) 

IGBFILLCOORD(VOL, BOUND, NBNODE, XYZ) 

This routine must be supplied for any call to giJbSetDiscret. Its responsibility is to fill the 
coordinate data associated with the bnodes. 


I: vol 
I: bound 
I: nbnode 
D: xyz 


Volume index 

Boundary index 

Number of Boundary nodes 

The 3-space coordinates for each bnode. Length is 3*nbn- 
ode (filled) 


gibFillTris(int vol, bound, ntris, *tris, *ctris) 

IGBFILLTRIS(VOL, BOUND, NTRIS, TRIS, CTRIS) 

This routine must be supplied if the call to gLbSetDiscret specifies any disjount triangles 
( ntris ^ 0). gibFillTris' responsibility is to fill the data required for disjoint triangles. 


I: vol 
I: bound 
I: ntris 
I: tris 


I: ctris 


Volume index 
Boundary index 

Number of disjoint triangles assigned to the Boundary 

3 bnode numbers are required for the definition of each 
triangle. The bnode numbers may come from either the set 
of disjoint nodes and/or the nodes defined via the quad- 
meshes. Length is 3*ntris (filled) 

The mesh 3D cell number containing the trianglar face. 
Note: This is not used internally by CAPRI. Length is 
ntris (filled) 


gibFillQuads(int vol, bound, nquads, *quads, *cquads) 

IGBFILLQUADS(VOL, BOUND, NQUADS, QUADS, CQUADS) 

This routine must be supplied if the call to gLbSetDiscret specifies any disjount quads 
( nquads ^ 0). gibFillQuads’ responsibility is to fill the data required for disjoint quadran- 
gles. 

I: vol Volume index 

I: bound Boundary index 
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I: nquacls 
I: quads 


I: cquads 


Number of disjoint quadrangles assigned to the Boundary 

4 bnode numbers are required for the definition of each 
quad. The bnode numbers may come from either the set 
of disjoint nodes and/or the nodes defined via the quad- 
meshes. Length is 4*nquads (filled) 

The mesh 3D cell number containing the quad face. Note: 
This is not used internally by CAPRI. Length is nquads 
(filled) 


gibFillQMesh(int vol, bound, nqmeshs, *block, *bsizes, *lims) 
IGBFILLQMESH(VOL, BOUND, NQMESHS, BLOCK, BSIZES, LIMS) 

This routine must be supplied if the call to gLbSetDiscret specifies any quad-meshes (i.e., 
nqmeshs ^ 0). gibFillQMesh’s responsibility is to fill the data required for faces of struc- 
tured blocks mapped to the Boundary. 


I: vol 
I: bound 
I: nqmeshs 
I: block 

I: bsizes 

I: lims 


Volume index 
Boundary index 

Number of quad-meshes touching the Boundary 

Block number (in the complete grid) with the associated 
mapping. Length is nqmeshs (filled) 

The sizes (.V/, Nj. N K ) for the block. Length is 3*nqmeshs 
(filled) 

6 entries that define the extent of the exposed block. The 
first 2 entries are the min and max indices for the first 
index (usually J). The next 2 entries are the min and 
max for the second index (J). The last 2 entries are the 
min and max indices for the last index (usually A). One 
of the set must be the same and numbering is 1 biased. 
For example: 1,1, 1,23, 10,100 - specifies the first / plane, 
with J going from the first index up to (and including) 23 
and I\ starting at 10 and continuing up to 100 specifying 
1980 quads. Length is 6*nqmeshs (filled) 


36 


gibFillDNodes(int vol, bound, ndnode, *nodes) 

IGBFILLDNODES(VOL, BOUND, NDNODE, NODES) 

This routine must be supplied if the call to gLbSetDiscret specifies any disjoint nodes 
( ndnode ^ 0) and CAPRI is to be used to translate bnode numbers back to 3D mesh 
indices (calls to gi-bGet3DXode are used). 

I: vol Volume index 

I: bound Boundary index 

I: ndnode Number of nodes used in the disjoint tris and quads. 

I: nodes 3D node number (in the complete grid). Length is ndnode 

(filled) 

E.2 GetDiscret - Returns data about the Discretization for the Boundary 

icode = gi_bGetDiscret(int vol, bound, *nbnode, *ndnode, *ntris, *nquads, 

*nqmeshs, *nattach, *nspecial) 

ICODE = IGJBGETDISCRET(VOL, BOUND, NBNODE, NDNODE, NTRIS, 

NQUADS, NQMESHS, NATTACH, NSPECIAL) 

This routine gets the sizes of grid discretization and the lengths for any associated data for 


the Boundary. 


I: vol 

Volume index 

I: bound 

Boundary index 

I: nbnode 

Number of bnodes found in the Boundary (returned) 
A zero indicates no discretization 

I: ndnode 

Number of disjoint bnodes found in the Boundary (re- 
turned) 

I: ntris 

Number of disjoint triangles (returned) 

I: nquads 

Number of disjoint quadrangles (returned) 

I: nqmeshs 

Number of quad-meshes (returned) 

I: nattach 

Number of associated attachments (returned) 

I: nspecial 

Number of associated special groups (returned) 

I: icode 

Return code 
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E.3 GetCoord - Returns the Boundary Discretization Coordinates 

icode = gi_bGetCoord(int vol, bound, *nbnode, double **xyz) 

ICODE = IG_BGETCOORD(VOL, BOUND, NBNODE, XYZ) 

This routine returns the coordinates associated with all of the bnodes. 


I: vol 

Volume index 

I: bound 

Boundary index 

I: nbnode 

Number of Boundary nodes (returned) 

D: xyz 

pointer to the 3-space coordinates for each bnode. Length 
of data is 3*nbnode (returned) 

I: icode 

Return code 


FORTRAN note: The pointer is not returned. NBNODE must be set with the size of 
XYZ at the call. It is returned with the actual length used. If XYZ is not declared large 
enough (by the calling routine) the return code CAPRI-OVERFLOW is set but all the data 
up to that length is correct. 

E.4 GetTris - Returns the Disjoint Triangle Discretization 


icode = gi_bGetTris(int vol, bound, *ntris, **tris, **ctris) 

ICODE = IGJBGETTRIS(VOL, BOUND, NTRIS, TRIS, CTRIS) 

This routine returns the list of disjoint tris defining the Boundary discretization. 


I: vol 

Volume index 

I: bound 

Boundary index 

I: ntris 

Number of disjoint triangles (returned) 

I: tris 

pointer to 3 bnode numbers for the definition of each tri- 
angle. Length of data is 3*ntris (returned) 

I: ctris 

pointer to the mesh 3D cell number containing the tri 
anglar face. Length of data is ntris (returned) 

I: icode 

Return code 


FORTRAN note: The pointers are not returned. NTRIS must be set with the size of 
TRIS and CTRIS at the call. It is returned with the actual length used. If the length is 
not large enough, then the return code CAPRI-OVERFLOW is set but all the data up to 
the declared length is correct. 
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E.5 GetQuads - Returns the Disjoint Quadrangle Discretization 

icode = gi_bGetQuads(int vol, bound, *nquads, **quads, **cquads) 

ICODE = IG_BGETQUADS(VOL, BOUND, NQUADS, QUADS, CQUADS) 

This routine returns the list of disjoint quads defining the Boundary discretization. 


I: vol 

Volume index 

I: bound 

Boundary index 

I: nquads 

Number of disjoint quadrangles (returned) 

I: quads 

pointer to 4 bnode numbers for the definition of each tri- 
angle. Length of data is 4*nquads (returned) 

I: cquads 

pointer to the mesh 3D cell number containing the quad 
face. Length of data is nquads (returned) 

I: icode 

Return code 

FORTRAN note: 

The pointers are not returned. NQUADS must be set with the size of 

QUADS and CQUADS at the call. It is returned with the actual length used. If the length 

is not large enough, 

then the return code CAPRI_0\ ERFLOW is set but all the data up 

to the declared length is correct. 

E.6 GetQMesh 

- Returns the Quad-Mesh Discretization 

icode = gi_bGetQMesh(int vol, bound, *nqmeshs, **block, **bsizes, **lims) 
ICODE = IGJ3GETQMESH(VOL, BOUND, BLOCK, BSIZES, LIMS) 

This routine returns the list of quad-meshes used in the Boundary discretization. 

I: vol 

Volume index 

I: bound 

Boundary index 

I: nqmeshs 

Number of quad-meshs in the Boundary (returned) 

I: block 

pointer to the block number (in the complete grid). Length 
of data is nqmeshs (returned) 

I: bsizes 

pointer to the sizes (A 7 /, Nj : Nk) for the block. Length of 
data is 3*nqmeshs (returned) 

I: lims 

pointer to 6 entries that define the extent of the exposed 
block. Length of data is 6*nqmeshs (returned) 

I: icode 

Return code 
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FORTRAN note: The pointers are not returned. NQMESHS must be set with the size 
of BLOCK, BSIZES and LIMS at the call. It is returned with the actual length used. If 
the length is not large enough, then the return code CAPRI_0\ ERFLOW is set but all the 
data up to the declared length is correct. 

E.7 Get3DNode - Translates the Boundary node to 3D node number 

icode = gi_bGet3DNode(int vol, bound, bnode, *type, *location) 

ICODE = IG_BGET3DNODE(VOL, BOUND, BNODE, TYPE, LOCATION) 

This routine returns the 3D mesh index associated with the bnode. 


I: vol 

Volume index 

I: bound 

Boundary index 

I: bnode 

Boundary node index - starts at 1. 

I: type 

Node type (returned) 

0 - from a node associated with disjoint primitives 

1 - from a node associated with quad-meshes 

I: location 

Mesh location (returned) 

Type 0: 3D Node number 

Type 1: /, J, K and Block # - 4 integers 

I: icode 

Return code 
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E.8 SetSpecial - Specify/Update a Special Grouping 

icode = gi_bSetSpecial(int vol, bound, char ♦name, int size) 

ICODE = IG_BSETSPECIAL(VOL, BOUND, NAME, SIZE) 

This routine specifies a Special listing (by name). These special groupings can be used to 
indicate lists of bnodes that may have special boundary condtions applied (such as at the 


Edge between two Boundaries), 
data. This routine will cause a 

. If the listing already exists, it is overwritten with the new 
call-back (documented next) to be executed. 

I: vol 

Volume index 

I: bound 

Boundary index 

C: name 

Listing name (i.e., "hub edge", "wing-body edge”) 

I: size 

The length of the list 

I: icode 

Grouping index/Return code 

gibFillSpecial(int vol, bound, char *name, int size, *list) 
IGBFILLSPECIAL(VOL, BOUND, NAME, SIZE, LIST) 

This call-back will be executed after a call to gLbSetSpecial. The routines responsibility is 
to fill the list requested for the grouping. 

I: vol 

Volume index 

I: bound 

Boundary index 

C: name 

Special grouping name 

I: size 

The number of entries for the list 

I: list, 

Special list - length is size (filled) 

E.9 GetSpecial - Return the info for a Special Grouping 

icode = gi_bGet Special (int vol, bound, char ’•‘name, int *size, **list) 
ICODE = IG_BGETSPECIAL(VOL, BOUND, NAME, SIZE, LIST) 

This routine returns data about a Special grouping (by name). 

I: vol 

Volume index 

I: bound 

Boundary index 

C: name 

Special grouping name 

I: size 

The length of the list (returned) 
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I: list 
I: icode 


pointer to the list - data length is size (returned) 
Return code 


FORTRAN note: The pointer is not returned. SIZE must be set with the length of LIST 
at the call. It is returned with the actual length used. If the length is not large enough, 
then the return code CAPRLOYERFLOW is set but all the data up to the declared length 
is correct. 

E.10 GetlSpecial - Get a Special Grouping by Index 


icode = gi_bGetISpecial(int vol, bound, index, char **name, int *size, **list) 
ICODE = IG_BGETISPECIAL(VOL, BOUND, INDEX, NAME, SIZE, LIST) 

This routine returns data about a Special grouping (by index). 


I: vol 

Volume index 

I: bound 

Boundary index 

I: index 

Grouping index - bais 1. 

C: name 

Grouping name (returned) 

I: size 

The length of the grouping (returned) 

I: list 

pointer to the list - data length is size (returned) 

I: icode 

Return code 

FORTRAN note: 

The pointer is not returned. SIZE must be set with the length of LIST 

at the call. It is returned with the actual length used. If the length is not large enough, 
then the return code CAPRLOYERFLOW is set but all the data up to the declared length 

is correct. 


E.ll DelSpecial 

- Remove a Special Grouping 

icode = gi_bDelSpecial(int vol, bound, char *name) 

ICODE = IG_BDELSPECIAL(VOL, BOUND, NAME) 

This routine deletes the data associated with a Special grouping. NOTE: the indices used 

with the groupings w 

ill be affected. 

I: vol 

Volume index 

I: bound 

Boundary index 

C: name 

Special listing name 

I: icode 

Return code 
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F Geometry Based Interpolation Routines 

F.l SetAttach - Specify/Update a Boundary Attachment 

icode = gi_iSetAttach(int vol, bound, char *name, int rank, char *update) 
ICODE = IG JSETATTACH(VOL, BOUND, NAME, RANK, UPDATE) 

This routine specifies a Boundary attachment (by name). If the attachment already exists, 
it is overwritten with the new data. This routine will cause call-back (documented next) to 


be executed. 



I: vol 


Volume index 

I: bound 


Boundary index 

C: name 


Attachment name (i.e., “pressure”, “heat transfer”) 

I: rank 


The number of entries per bnode. i.e., scalars are 1, vec- 
tors are 3 (or -3 - do not apply replication/displacement). 

C: update 


A character string to indicate something about the at- 
tachment. For example, if the simulation is transient this 
could contain the solvers time when last filled. 

I: icode 


Attachment index/Return code 

giiFillAttach(int vol, bound, char *name, int rank, char *update, int nbnode, 
double *data) 

IGIFILLATTACH(VOL, BOUND, NAME, RANK, UPDATE, NBNODE, 
DATA) 

This call-back will be executed after a call to gLiSetAttacli that specifies a non-zero rank. 
The routines responsibility is to fill the data requested for the attachment. 

I: vol 


Volume index 

I: bound 


Boundary index 

C: name 


Attachment name 

I: rank 


The number of entries per bnode 

C: update 


A character string to indicate something about the attach- 
ment. 

I: nbnode 


Number of boundary nodes 

D: data 


Attached data - length is rank*nbnode (filled) 
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F.2 GetAttach - Get a Boundary Attachment 


icode = giJGet Attach(int vol, bound, char *name, int *rank, char **update, 

int *nbnode, double **data) 

ICODE = IG_IGETATTACH(VOL, BOUND, NAME, RANK, UPDATE, 

NBNODE, DATA) 

This routine returns data about a Boundary attachment (by name). 


I: vol 


Volume index 

I: bound 


Boundary index 

C: name 


Attachment name 

I: rank 


The number of entries per bnode (returned) 

C: update 


pointer to the update character string (returned) 

I: nbnode 


Number of boundary nodes (returned) 

D: data 


pointer to attached data - data length is rank*nbnode 
(returned) 

I: icode 


Return code 

FORTRAN note: The pointer is not returned. NBNODE must be set with the size of 
DATA at the call. It is returned with the actual length used. If the length is not large 
enough, then the return code CAPRI-OVERFLOW is set but all the data up to the declared 

length is correct. 


F.3 GetlAttach 

- Get a Boundary Attachment by Index 

icode = gi-iGetIAttach(int vol, bound, index, char **name, int *rank, 

char **update, int *nbnode, double **data) 
ICODE = IGJGETI ATTACH (VOL, BOUND, INDEX, NAME, RANK, 

UPDATE, NBNODE, DATA) 

This routine returns data about a Boundarj' attachment (by index). 

I: vol 


Volume index 

I: bound 


Boundary index 

I: index 


Attachment index - bais 1. 

C: name 


Attachment name (returned) 

I: rank 


The number of entries per bnode (returned) 
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C: update 
I: nbnode 


pointer to the update character string (returned) 

Number of boundary nodes (returned) 

D: data pointer to attached data - data length is rank*nbnode 

(returned) 

I: icode Return code 

FORTRAN note: The pointer is not returned. NBNODE must be set with the size of 
DATA at the call. It is returned with the actual length used. If the length is not large 
enough, then the return code CAPRI-OVERFLOW is set but all the data up to the declared 
length is correct. 

F.4 DelAttach — Remove a Boundary Attachment 

icode = gi_iDelAttach(int vol, bound, char *name) 

ICODE = IGJDEL ATTACH (VOL, BOUND, NAME) 

This routine deletes the data associated with a Boundary attachment. NOTE: the indices 
used with the attachments will be affected. 

I: vol Volume index 

I: bound Boundary index 

C: name Attachment name 

I: icode Return code 

F.5 GetDisplace - Gets the Volume’s displacement matrix 

icode = gi_iGetDisplace(int vol, double *dmatrix) 

ICODE = IG JGETDISPLACE(VOL, DMATRIX) 

This routine returns the displacement matrix associated with the specified volume. The 
displacement matrix is a column-major matrix that is 4 columns by 3 rows and declared 
in C as [4][3] and in FORTRAN as (3,4). This matrix is used to multiply all Volume 
coordinates before interpolation is performed and therfore supports any combination of 
displacement, rotation and scaling. 

I: vol \ olume index 

D: dmatrix The displacement matrix 

I: icode Return code 
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F.6 SetDisplace - Set the Volume’s displacement matrix 


icode = gLiSetDisplace(int vol, double *dmatrix) 

ICODE = IG JSETDISPLACE(VOL, DMATRIX) 

This routine specifies the displacement matrix associated with the specified volume. The 
displacement matrix is a column-major matrix that is 4 columns by 3 rows and declared in 
C as [4] [3] and in FORTRAN as (3,4). 

I: vol Volume index 

D: dmatrix The displacement matrix 

I: icode Return code 


F.7 GetReplicate — Gets the Volume’s replication data 


icode — gi_iGetReplicate(int vol, *nrep, double *rmatrix) 

ICODE = IG JGETREPLICATE(VOL, NREP, RMATRIX) 

This routine returns the replication data associated with the specified volume. This in- 
formation is comprised of a matrix and the number of times to apply this matrix to the 
Volume. The replication matrix is a column-major matrix that is 4 columns by 3 rows 
and declared in C as [4] [3] and in FORTRAN as (3,4). This matrix is used to multiply 
all Volume coordinates in order to produce additional instances of the Voulme (before the 
Displacement matrix is applied) and then the interpolation is performed. When properly 
used this allows mirroring and periodic volumes (like found in turbomachinery). 


I: vol 
I: nrep 
D: rmatrix 
I: icode 


Volume index 

Number of times to apply the matrix 
The replication matrix 
Return code 
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F.8 SetRepIicate - Set the Volume’s replication data 


icode = gi _iSetReplicate(int vol, nrep, double *dmatrix) 

ICODE = IG JSETREPLICATE(VOL, NREP, RMATRIX) 

This routine specifies the replication data associated with the specified volume. The repli- 
cation matrix is a column-major matrix that is 4 columns by 3 rows and declared in C as 
[4] [3] and in FORTRAN as (3.4). nrep set to zero turns off all replication. 


I: vol 
I: nrep 
D: rmatrix 
I: icode 


Volume index 

Number of times to apply the matrix 
The replication matrix 
Return code 


F.9 InterAttach - Interpolate to Produce/Update Boundary Attachment 

icode = gi _iInterAttach(int vol, bound, char *name, int void, boundd, 

char *named, *updated) 

ICODE = IGJINTER ATTACH (VOL, BOUND, NAME, VOLD, BOUNDD, 

NAMED, UPDATED) 

This routine interpolates the source attachment onto the discretization for the destination 
boundary. A new attachment is created if NAMED does not already exist, otherwise the 
data is replaced. Any rank 3 Attachments have the displacement and replication matrices 
applied (just like the coordinates). 


I: vol 

Volume index - source 

I: bound 

Boundary index - source 

C: name 

Attachment name - source 

I: void 

Volume index - destination 

I: boundd 

Boundary index - destination 

C: named 

Attachment name - destination 

C: updated 

The update character string - destination 

I: icode 

Return code 
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G Tag Routines 

G.l GetNumVolume - Returns the number of Volume Tags 

icode = gLtGetNumVolume(int vol, *num) 

ICODE = IG_TGETNUMVOLUME(VOL, NUM) 

This routine returns the number of Tags for the Volume. 


I: vol 

\'olu me index 

I: num 

Number of Tags associated with this Volume 

I: icode 

Return code 

G.2 Get Volume - 

- Gets the Volume Tag 


icode = gi_tGetVolume(int vol, char *tag, **val) 
ICODE = IG_TGETVOLUME(VOL, TAG, VAL) 

This routine returns the string associated with the \olume Tag. 

I: vol Volume index 

C: tag The Tag string 

C: val The associated string 

I: icode Return code 

G.3 Get! Volume - Gets the Volume Tag by index 


icode = gi_tGetIVolume(int vol, index, char **tag, **val) 

ICODE = IG_TGETIVOLUME(VOL, INDEX, TAG, VAL) 

This routine returns the string associated with the index for the Volume Tag. 


I: vol 

Volume index 

I: index 

Tag index - range 1 to the number of Tags. 

C: tag 

The Tag string 

C: val 

The associated string 

I: icode 

Return code 
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G.4 Set Volume - Sets the Volume Tag 


icode = gi_t Set Volume (int vol, char *tag, *val) 

ICODE = IG_TSET VOLUME (VOL, TAG, VAL) 

This routine sets the string associated with the Volume Tag. If the Tag exists the new 
string is applied. 


I: vol 

Volume index 

C: tag 

The Tag string 

C: val 

The associated string - A NULL value deletes the Tag, 

I: icode 

Return code 


G.5 GetNumBoundary - Returns the number of Boundary Tags 

icode = gi_tGetNumBoundary(int vol, bound, *num) 

ICODE = IG-TGETNUMBOUNDARY (VOL, BOUND, NUM) 

This routine returns the number of Tags for the Boundary. 


I: vol 

Volume index 

I: bound 

Boundarj' index 

I: num 

Number of Tags associated with this Boundary 

I: icode 

Return code 


G.6 GetBoundary - Returns the Boundary Tag 

icode = gi_t GetBoundary (int vol, bound, char *tag, **val) 
ICODE = IG-TGETBOUNDARY (VOL, BOUND, TAG, VAL) 

This routine returns the string associated with the Boundary Tag. 


I: vol 

Volume index 

I: bound 

Boundary index 

C: tag 

The Tag string 

C: val 

The associated strin; 

I: icode 

Return code 
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G.7 GetIBoundary - Gets the Boundary Tag by index 

icode = gi_tGetIBoundary(int vol, bound, index, char **tag, **val) 
ICODE = IG.TGETIBOUNDARY (VOL, BOUND, INDEX, TAG, VAL) 

This routine returns the string associated with the index for the Boundary Tag. 


I: vol 


Volume index 

I: bound 


Boundary index 

I: index 


Tag index - range 1 to the number of Tags. 

C: tag 


The Tag string 

C: val 


The associated string 

I: icode 


Return code 

G.8 SetBoundary 

— Sets the Boundary Tag 

icode = gi_tSetBoundary(int vol, bound, char *tag, *val) 

ICODE = IG_TSETBOUNDARY(VOL, BOUND, TAG, VAL) 

This routine sets the string associated with the Boundary Tag. If the Tag exists the 
string is applied. 

I: vol 


Volume index 

I: bound 


Boundary index 

C: tag 


The Tag string 

C: val 


The associated string - A NULL value deletes the Ta ( 

I: icode 


Return code 
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H Return Codes 


-12 - CAPRI.XOTFOUXD 
-11 - CAPRI.XODISCRET 
-10 - CAPRI-OVERFLOW 
-9 - CAPRI JXUSE 
-8 - CAPRI-RAXGERR 
-7 - CAPRIJMODELERR 
-6 - CAPRI-XOLOAD 
-5 - CAPRIJNDEX 
-4 - CAPRLUXSUPPORT 
-3 - CAPRI A I ALLOC 
-2 - CAPRI-ALREADYOX 
-1 - CAPRI-XOIXIT 

0 - CAPRI-SUCCESS 

1 - CAPRLOUTSIDE - Not an error 
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Budget Summary 


From February 6, 1998 to 

1. Direct Labor (salaries, wages, and 
fringe benefits) 

2. Other Direct Costs: 

a. Subcontracts 

b. Consultants 

c. Equipment 

d. Supplies 

e. Travel 

f. Other 

3. Indirect Costs 

4. Other Applicable Costs 

5. Sub-total — Estimated Costs 

6. Less Proposed Cost Sharing (if any) 

7. Carryover Funds (if any) 

a. Anticipated Amount 0 

b. Amount used to reduce budget 

8. Total Estimated Costs 
APPROVED BUDGET 


February 5, 1999 

NASA USE ONLY 

ABC 

41,794 

0 _ 

0 _ 

0_ 

240 

3,630 

875 

29,552 

0 _ 

76,091 

0 


0 _ 

76,091 XXXXXXX 

XXXXXXX XXXXXXX 


Instructions 

1 - Provide a separate budget summary sheet for each year of the proposed research. 

2. Grantee estimated costs should be entered in Column A. Columns B and C are for NASA 
use only. Column C represents the approved grant budget. 

3. Provide in attachments to the budget summary the detailed computations of estimates in 
each cost category, along with any narrative explanation required to fully explain proposed 
costs. 


ADDITIONAL INSTRUCTIONS ON REVERSE 


PROPOSED COST ESTIMATE 
2 / 6 / 98 - 2 / 5/99 


SALARIES & WAGES 

Principal Research Engineer (Haimes) 

Res. Administrative Staff 
Project Support Staff 

TOTAL SALARIES & WAGES 

EMPLOYEE BENEFITS (excluding UROP) @ 

EMPLOYEE BENEFITS (excluding Res. Asst. & UROP) @ 
VACATION ACCRUAL (excluding Professors and students) @ 

OTHER COSTS 
Travel (Domestic) 

Office Supplies, xerox, telephone, postage 
Report Costs 

TOTAL OTHER COSTS 

TOTAL DIRECT COSTS 

INDIRECT COSTS (F&A) @ 

TOTAL 



2/6/98- 

6/30/98 

7/1/98- 

2/5/99 

Total 

30% 

10,319 

15,400 

25,719 

5% 

1,031 

1,539 

2,570 

4% 

417 

626 

1,043 


11,767 

17,565 

29,332 

46.2% 

5,436 

- 

5,436 

29% 

- 

5,094 

5,094 

11% 

- 

1,932 

1,932 


1,462 

2,168 

3,630 


97 

143 

240 


352 

523 

875 


1,911 

2,834 

4,745 


19,114 

27,425 

46,539 

63.5% 

12,137 

17,415 

29,552 


31,251 

44,840 

76,091 



Backup Information 


Page 1 


Direct Labor 


Number 

Title 

MM 

Current Salarv 
Base f see note 1 ) 

Salarv Increase 
Effective 

1 

Principal Research Engineer (Haimes) 

3.6 

82,100 /year 

January 1 

1 

Research Administrative Staff (see note 2) 

0.6 

49,250 /year 

January 1 

1 

Project Support Staff (see note 2) 

0.48 

25,350 /year 

April 1 


Employee Benefits (UROP excluded) @ 46.2% FY' 98 

Employee Benefits (Research Assistants & UROP excluded) @ 29% FY' 99 and out years (see note 3 ) 
Vacation Accrual (excluding Professors and students) @ 11% ( see note 4 ) 

Other Costs 

Office supplies, xerox, telephone toll calls, and postage currently averages $20 per month based on past history 
Report Costs--Page charges in a professional journal (based on AIAA rate of S875 per journal article) 


Travel 


Destination: Cleveland, OH 



Destination: Cincinnati 



No. of People 

1 

No. of People 

1 


No. of days 

3 

No. of days 

3 


No. of Trips 

2 

No. of Trips 

1 

Air Fare (full coach) @ 


750.00 

Air Fare@ 

750.00 

Hotel (per day) @ 

$75 

225.00 

Hotel @ $75 

225.00 

Food (per day) @ 

$25 

75.00 

Food @ $25 

75.00 

Rental Car (per day) @ 

$45 

135.00 

Rental Car @ $45 

135.00 

Misc (taxi, tel calls, Parking, etc) @ 

$25 _ 

25.00 

Misc @ $25 _ 

25.00 


Total per person trip 

1210.00 

Total per person trip 

1210.00 


Total 

2420.00 

Total 

1210.00 


Indirect Costs @ 63.5% of total direct costs excluding Equipment for MIT FY '98 

Indirect Costs (Facilities & Administrative) @ 63.5% of total direct costs for MIT FY '99 and out years 

NOTES: 

(1) Salary increases @ 4% rounded to nearest $100 and are current as of Nov-97 

(2) 5% of Adminstrative and clerical support is budgeted as an estimate of time required to provide clerical and administrative 
support for the P.l. as required for the performance of this project. Duties include but are not limited to the following: verifying 
payroll distribution, arrangement of travel relative to this project, submittal of appropriate forms to MIT purchasing, accounting, 
sponsored programs and other offices to meet regulatory, auditing and compliance requirements. 

(3) At the present time, the tuition of graduate research assistants is charged to the employee benefit pool and the stipend to the 
research account. Beginning July 1, 1998, RA tuition will no longer be included in the employee benefit pool. The net effect of this 
change will be an estimated reduction of 17.2 points in the on campus EB and 22.9 points in the off-campus EB. None of the RA cost 
will be subject to the EB rate, and the tuition will not be subject to either EB or 

(4) Vacation accrual, beginning July 1, 1998, has been removed from the EB rate and vacation accrual costs are distributed only to 
those salary groups (research, hourly and support staff) which are actually accrued. This charge will bear the prevailing research 
F&A rate. 



